Thanks for your pull request, @MartinNowak!

Bugzilla references

I'm okay with this approach as opposed to clever games with static shared this(). @WalterBright ?

This tool is useful despite shared static this() and -betterC, but indeed, once it's there, we don't necessarily need to alter shared static this().

Perhaps a test that attaches the pragam to something else than a function.

Perhaps a test that attaches the pragam to something else than a function.

Done

What about static methods in a class or struct?

What about static methods in a class or struct?

Works, this is a low-level tool (just as pragma(startaddress)), it will just stuff any pointer into the init/fini section, no matter what ABI or params. If that happens to be compatible with extern(C) void func() it won't crash.

It would be nice with a test for that.

It would be nice with a test for that.

It's too low-level, I wouldn't want to promise that for all ABIs, use at your own risk.

This tool is useful despite shared static this() and -betterC, but indeed, once it's there, we don't necessarily need to alter shared static this().

A short list of pros and cons of the approaches woudl be very helpful.

This PR is not about -betterC, let's keep that discussion in #6956 please.

Ping @WalterBright, @andralex. Anything preventing us from adding that feature for low-level runtime hackers and C++ interop?

@WalterBright I'm good to go with this, will approve.

Thank you @MartinNowak for doing this work, especially the fixing of the *obj.c files.

My complaint centers around using an awkward pragma to do the dirty work. It has the effect of putting every function in its scope into the initializer list, which is a bit bizarre as I can't imagine code needing that. A better placement for the pragma would be inside the function body, which would avoid the need for the recurse() function. The recurse() function provokes questions we shouldn't need to answer (like why not affect the static member functions of an aggregate?).

The complaints around shared static this() are that it changes the semantics. But -betterC is expected to change the semantics to not use druntime, and shared static this() requires druntime. So it is ok to use it for betterC to do the construction/destruction. -betterC changes semantics on other bits of code, too. It's not going to break code.

Another issue is if one is not using -betterC, but wishes to install a function into the C ctor/dtor list. One way is for the user to put such code into a separate file, compile that file with -betterC, and link it in. Another way is to do this:

extern (C) void init() { ... }
pragma(crt_constructor, init);

extern (C) void fini() { ... }
pragma(crt_destructor, fini);

This also avoids the need for the recurse() function.

That's mostly because it's a function attribute (pragma) everywhere else, e.g. gdc/ldc/GCC/clang.
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
https://wiki.dlang.org/LDC-specific_language_changes#LDC_global_crt_ctor_and_LDC_global_crt_dtor

The recursion was added to deal with things like the following and maybe template functions.

pragma(crt_constructor)
version (linux) void init() {}

I could instead change it to check that it directly applies to a function.
Behaving like pragma(mangle, seems also reasonable.

Do we have a precedent of a pragma only applicable to one declaration? If not, would an attribute a la @__crt_constructor be more appropriate?

Is it really a function attribute? It doesn't affect the function signature or ABI. Given the salad of attributes we have, adding more kinda scares me, especially for one so rarely used as this one. Recall how C++'s volatile, rarely used, wound up with an enormously outsized impact on the spec. Whatever we pick should have an impact on the spec in proportion to its use cases.

The recursion was added to deal with things like the following and maybe template functions.

I don't find the recursive example compelling enough to have to explain why it doesn't affect aggregate member functions. Let's pick something that will be easy to document.

Is it really a function attribute? It doesn't affect the function signature or ABI.

Why do you think a function attribute does have to affect the signature or API? We also have UDAs and these are simply defined as compile time only meta-data for certain declarations. Recognize some special cases in the compiler and they are a perfect fit for such situations. LDC and GDC already do this for years:
https://wiki.dlang.org/LDC-specific_language_changes#Attributes
https://wiki.dlang.org/Using_GDC#Attributes
There's also precedent in GCC using function attributes which do not affect ABI or signature instead of introducing pragmas for these cases: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

The mangle pragma is also a perfect fit for such an UDA. I really don't understand why DMD doesn't just finally follow the other compilers lead here to introduce a dmd.attribute module:

// If you don't want the import in user code, add a public import to object.d instead
import dmd.attribute;

@crt_constructor void foo() {}
@crt_destructor @mangle("some_mangled_name") void bar() {}

You even get compile-time reflection to detect whether any such attribute is applied to a function for free, there's no global namespace pollution, and there are many more benefits. We have this nice UDA feature, why not use it?

I really don't understand why DMD doesn't just finally follow the other compilers lead here to introduce a dmd.attribute module:

We already have core.attribute [1]. But of course, not that many knows about it because currently there's only one attribute in that module, @selector, which is used for Objective-C bindings.

[1] https://github.com/dlang/druntime/blob/master/src/core/attribute.d

Can we please keep the attribute discussion off here, it's a necessary, but separate discussion.

So far similar functionality was implemented as pragmas, and there isn't even functionality to recognize special attributes in dmd yet. It's also a pragma declaration in LDC.
Reflection for crt_con-/destructor, weak, or section doesn't seem necessary either.

BTW, that's the second time this review takes a detour into an slightly OT discussion.

Another issue is if one is not using -betterC, but wishes to install a function into the C ctor/dtor list. One way is for the user to put such code into a separate file, compile that file with -betterC, and link it in.

That's hardly feasible as it required changing build tools to compile one module with different flags. It also changes the other semantics of that module.

I don't find the recursive example compelling enough to have to explain why it doesn't affect aggregate member functions. Let's pick something that will be easy to document.

This PR has already been updated to handle this in the same way as pragma(mangle).
See https://github.com/dlang/dmd/pull/7182/files#diff-a1d1c80dad91d10a8b21b88b0155d54fR1150 and https://github.com/dlang/dmd/pull/7182/files#diff-c9ea52bf15f25ece8c552886cfc67993R6.

My complaint centers around using an awkward pragma to do the dirty work

FWIW in LDC we have
pragma(LDC_global_crt_[c|d]tor [, priority]) { funcdecl(s) } where priority is a ushort.

FWIW in LDC we have
pragma(LDC_global_crt_[c|d]tor [, priority]) { funcdecl(s) } where priority is a ushort.

Yes, as mentioned in #7182 (comment).
After some initial attempts, priority was left out, as it cannot be properly supported on all platforms.

Can we please settle the bike-shedding on pragma vs. attributes vs. pragma with function name. This PR is implemented just like pragma mangle, and now doesn't allow more than one function.

After some initial attempts, priority was left out, as it cannot be properly supported on all platforms.

Does it need to be? it would be nice to drop LDC's specific ones and use the dmd ones (LDCs is also a block pragma but that is less of an issue). Having said that I'm not sure how widely they are used. CRT constructors are rather rare and specifying a priority is even more rare.

Perhaps you could make the priority optional and implementation defined?

No, we went through this, LDC/GDC can keep their pragmas with priority support and map the one added in this PR to the default priority. As you said there is hardly any use-case for priorities to begin with, and even with ldc/gdc priorities were not global, but local (translation unit).

Fair enough.

@MartinNowak now when this is merged, how does this related to the obj_rtinit [1] function in the compiler? Can that function be completely removed, or parts of it?

[1]

crt_constructor is not allow to set static immutable.

static immutable int my_i ;
int test(){
	return 3;
}

shared static this(){
	my_i = test();  // work 
}
pragma(crt_constructor) extern(C) void init1(){
	my_i = test(); //   Error: cannot modify immutable expression my_i
}

@changloong You could raise a bug on that instead of commenting here.

@jacob-carlborg - I will assume no, because it needs to be emitted into every DSO.

@ibuclaw thanks for tip
add bug: https://issues.dlang.org/show_bug.cgi?id=18100

Thanks for this killer feature for betteC programs.

Tested with mir-cpuid, DMD segfaults if -lib flag is passed
https://issues.dlang.org/show_bug.cgi?id=18456

Bit late, but specs PR is here: dlang/dlang.org#2757